View AN3324_8216511.PDF datasheet online --- IC-ON-LINE

Datasheet File OCR Text:

september 2013 doc id 18311 rev 2 1/37 AN3324 application note implementing power-on self tests for spc56el60 in locked step introduction spc56el60 is a 32-bit system-on-chip (soc) automotive microcontroller designed for safety applications with a focus to minimize software measures within the cpu core subsystem. in order to reach this state, several softwa re measures are required during the mcu power- on start-up procedure. this application note describes the software measures that user must perform after the boot in order to detect and manage latent faults. this document is valid only under the assumption that the mcu is used in locked step for automotive applications with fail- silent or fail-indicate micros. this application note is based on an3077 rev. 2 (see b.1: reference documents ). all the topics covered in this document also refer to rm0032 rev. 5, spc56el60l3, spc56el60l5 datasheet rev. 5 and an3121 rev. 1 (see b.1: reference documents in appendix b ). this application note applies to spc56el60 devices according to ta bl e 1 . table 1. device summary part number package spc56el60l3 lqfp100 (3.3 v) spc56el60l5 lqfp144 (3.3 v) www.st.com
AN3324 contents doc id 18311 rev 2 2/37 contents 1 document hierarchy . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6 2 how to implement power-on self test features . . . . . . . . . . . . . . . . . . . . 7 2.1 mcu initialization . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7 2.1.1 safety initialization . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8 2.2 safety verification and faults checking . . . . . . . . . . . . . . . . . . . . . . . . . . . 10 3 module software requirem ents for non applicative peripherals . . . . . 12 3.1 system status and configuration module (sscm) . . . . . . . . . . . . . . . . . 12 3.2 self test control unit (stcu) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12 3.3 redundancy control checker unit (rccu) . . . . . . . . . . . . . . . . . . . . . . . 13 3.4 reset generation module (mc_rgm) . . . . . . . . . . . . . . . . . . . . . . . . . . . 13 3.5 fault collection and control un it (fccu) . . . . . . . . . . . . . . . . . . . . . . . . 13 3.6 clock configuration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15 3.7 clock monitor unit (cmu) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18 3.8 frequency-modulated phase-locked loop (fmpll) . . . . . . . . . . . . . . . . 18 3.9 internal rc oscillator (ircosc) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19 3.10 flash memory . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19 3.10.1 array integrity self check procedure . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20 3.11 temperature sensors . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21 3.12 software watchdog timer (swt) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21 3.13 power management unit (pmu) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22 4 module software requirement s for applicative peripher als . . . . . . . . 24 4.1 analog to digital converter (adc) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24 4.1.1 self test algorithms . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24 4.1.2 analog watchdog . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 26 5 summary . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 27 appendix a cpu core initializa tion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 28 a.1 cpu register initiliazation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 28 a.2 example of spc56el60 boot file for flash . . . . . . . . . . . . . . . . . . . . . . . . 29
contents AN3324 3/37 doc id 18311 rev 2 appendix b additional information. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 34 b.1 reference documents . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 34 b.2 acronyms . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 34 revision history . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 36
AN3324 list of tables doc id 18311 rev 2 4/37 list of tables table 1. device summary . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1 table 2. fault assertion conditions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22 table 3. spc56el60 registers to initialize . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 29 table 4. acronyms . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 34 table 5. document revision history . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 36
AN3324 list of figures doc id 18311 rev 2 5/37 list of figures figure 1. initialization flow . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8 figure 2. safety initialization flow. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9 figure 3. faults check flow . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11 figure 4. fccu configuration flow . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14 figure 5. spc56el60 system clock generation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16 figure 6. clock configuration flow . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17 figure 7. built-in self test flow . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22 figure 8. pmu power-on self test flow . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23 figure 9. adc self test in cpu mode using one shot sequence . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25 figure 10. spc56el60: checking flow . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 28
AN3324 document hierarchy doc id 18311 rev 2 6/37 1 document hierarchy the safety application guid e (sag) (please refer to an3077 , see b.1: reference documents in appendix b ) is the reference document to use. this application note is focused to describe the individual software measures. the sag describes which measure to apply according to the application and peripheral usage. the hints that are described in this document should be considered as proposals to implement the requirements described in spc56el60 sag. based on their applications and the sag, user can decide to use different implementations.
AN3324 how to implement power-on self test features doc id 18311 rev 2 7/37 2 how to implement power-on self test features the goal of this application note is to show how users can implement properly the safety initialization and the self tests to allow to detect latent fault (a) and to manage them. 2.1 mcu initialization at power-on, after regist er initialization (see section 3.3: redundancy control checker unit (rccu) ) and other basic initializations (mmu config uration, stack initia lization, etc.) (see appendix a: cpu core initialization ) user software has to verify if mcu is in alarm state or in safe mode (coming from a reset condition) (see section b.1: reference documents in appendix b ) and in that case must manage fault causes. if current mode in mode entry module is default run mode (drun), software can proceed with the default safety mcu initializat ion with self test features (see figure 1: initialization flow ). note: user can verify alarm state by reading non critical fault on fccu while he can verify safe mode by reading current mode field (gs register) on mode entry module. a. latent fault: multiple point fault whose presence is not detected by a safety mechanism nor perceived by the driver within the multiple point fault detection interval.
AN3324 how to implement power-on self test features doc id 18311 rev 2 8/37 figure 1. initialization flow 2.1.1 safety initialization figure 2 shows an example of how to implement a safety initialization (see section 3: module software requirements for non applicative peripherals ). user should take care that: 1. execution order is not mandatory but it is strongly recommended (see figure 2: safety initialization flow ). 2. swt (software watchdog timer) is enabled. 3. rgm (re set generation module) and fccu (fault collection and control unit) must be configured before all monitors or detectors are initialized. mcu initialization reset check faults fault manager fccu in safe state or alarm state no yes user code read non critical faults cpu core initialization
AN3324 how to implement power-on self test features doc id 18311 rev 2 9/37 figure 2. safety initialization flow disable swt init fccu begin enable all peripherals end init rgm init magic carpet (me-clocks-fmpll-wait states) inhibit bam execution configure cmu init peripheral bridge init and enable irq management
AN3324 how to implement power-on self test features doc id 18311 rev 2 10/37 2.2 safety verification and faults checking at the end of safety initialization, user software has to verify some basic safety requirements and verify if there is any fault (see section 3: module software requirements for non applicative peripherals ). figure 3 shows an example of how to implement the faults check flow.
AN3324 how to implement power-on self test features doc id 18311 rev 2 11/37 figure 3. faults check flow begin end fault manager mcu in lock step flash array integrity check stcu check pmu check irc check temperature check configure swt yes yes yes yes yes yes yes swt check no no no no no no no
AN3324 module software requirements for non applicative peripherals doc id 18311 rev 2 12/37 3 module software requirements for non applicative peripherals this chapter describes the requirements of the software modules that should check the system peripherals and the flash. the checks are required for any application. the peripherals treated in this chapter are accounted as non applicable peripherals because they are not involved directly in an y application safety integrity function (sif) please refer to an3077 (see b.1: reference documents in appendix b ). 3.1 system status and co nfiguration module (sscm) before executing safety functions, user must perform two actions: 1. configure the sscm to inhibit unintentional execution of the bam code. note: this requirement is satisfied by asserting the flag pae in the error register of the sscm. each access to the bam memory area produces a prefetch or abort exception. 2. verify that the device operates in lock-step mode (lsm). note: software needs to check this condition by reading the lsm flag in the system status register (sscm_status) and verifying that the device is operated in the intended mode of operation. 3.2 self test control unit (stcu) after boot, user softwa re must check the stcu to ensure its reliabilit y. the software must perform several operations based on the stcu status conditions after the power-on self test. even if no errors are reported, user software should confirm that the expected and actual values within the crc (cyclic redundanc y check) and lbist misr registers do not indicate an error. this software confirmation prevents a fault within the stcu itself incorrectly indicating that the self test passed. in the case of no reported errors, user software should confirm that: 1. the internal crc computation result matches the expected value. note: read the crce and crcr registers to check the coherency with the stcu_err[crcs] flag. 2. the signature registers of each of the lbist results match their corresponding expected values. note: for each lbist, read the stcu_lbmisrel/h and stcu_lbist_nmisrrl/h registers to check the coherency with the stcu_lbs bits. 3. read the registers used for reported erro rs and verify that their values are as expected. refer to the ?integrity sw operations? section in rm0032 (see b.1: reference documents in appendix b ) . note: verify that stcu_lbs, stcu_lbe, stcu_mbsl, stcu_mbel flag registers values are as expected. (lbist and mb ist finished with success).
AN3324 module software requirements for non applicative peripherals doc id 18311 rev 2 13/37 this is an additional safety layer since the stcu propagates the l/mbist and internal faults using the cf/ncf lines toward fccu. so reading the above registers helps in increasing the stcu auto-test coverage. 3.3 redundancy contro l checker unit (rccu) the rccu unit performs a cycle-by-cycle comparison of the outputs of the modules included in the sphere of replication (sor) (b) . the rccu is able to detect any mismatch between the outputs of two replicated modules. the error information is forwarded to the reset generation module (rgm) (see section 3.4: reset generation module (mc_rgm) ) and to the fault collection and control unit (fccu) (see section 3.5: fault collection and control unit (fccu) ). fault injection for the rccus controlled by the fccu is provided pr imarily for software development and validation purposes. the rccu?s are only enabled when spc56el60 is in the lsm mode. note: application software must assert that the lsm mode is activated (see section 3.1: system status and configuration module (sscm) ). rccu is automatically managed by the spc56el60 device and user cannot disable it. 3.4 reset generation module (mc_rgm) user has to configure mc_rgm and fccu (fault collection and control unit) (see section 3.5: fault collectio n and control unit (fccu) ) to react to critical application faults. user has to trigger reset sequence when one of the following events happen: a cmu1/2 clock freq. too high/low event a pll1 fail event a system clock freq. too high/low event a oscillator freq. too low event a pll0 fail event a core watchdog reset event note: rgm_ferd (functional event re set disable register) set to zero so that all events trigger a reset sequence. user should set to zero rgm_fear (functional event alternate request register) to allow to generate a safe mode request on events if the reset is disabled. 3.5 fault collection and control unit (fccu) user has to configure the fccu so that it reacts to generate a functional reset or so that it forces the mcu to switch in fail safe. it is possible to configure the reaction for eac h fault source and ensuring the rule described above is valid for each individual source. b. the sor is the logical part of the de vice that contains all the modules th at are replicated for functional safety reasons.
AN3324 module software requirements for non applicative peripherals doc id 18311 rev 2 14/37 the only exception to this rule is when the cmu monitors a pll that is not used or is used for non safety critical modules only. in this case, error masking and limited internal reaction can be tolerated. external reaction of the fccu is always enabled and it can not be disabled. user has to verify that no critical fault (cf) or non critical fault (ncf) are present after the boot. note: the application has to configure the fccu to enable all reactions related to faults of peripherals used by the application safety function (see figure 4: fccu configuration flow ). figure 4. fccu configuration flow configure time-out configure critical faults reaction begin enter config state configure non critical faults reaction configure output protocol enable fccu irq with proper priority set normal state end
AN3324 module software requirements for non applicative peripherals doc id 18311 rev 2 15/37 3.6 clock configuration the system starts up using th e internal rc oscillator clock as clock source. refer to the ?ircosc 16 mhz internal rc os cillator? section in rm0032 (see b.1: reference documents in appendix b ) for detailed informations abo ut the internal oscillator. user has to configure the fm plls to use the clock signal from the external oscillator (xosc) as a clock source before any safety functions are executed. note: select field in the cgm_ac3_sc and cgm_ac4_sc have to be set to 1. see figure 5: spc56el60 system clock generation . all safety-relevant ip modules are clocked with a fmpll-generated clock signal to reduce the impact of glitches stemming from the external quartz crystal and its connection to the mcu. note: this requirement is fulf illed by appropriately progra mming the mc_cgm and mc_me modules. see figure 6: clock configuration flow to see what is the correct way to configure clock and fmplls.
AN3324 module software requirements for non applicative peripherals doc id 18311 rev 2 16/37 figure 5. spc56el60 system clock generation rc-o s cill a tor (irco s c) o s cill a tor (xo s c) 4 mhz?16 mhz 40 mhz xo s c_clk 8 mhz irco s c_clk_ s 16 mhz mc_cgm aux clock s elector 4 aux clock s elector 3 fmpll_0 120 mhz fmpll_1 120 mhz phi_pc s phi phi fvco y 6 fmpll_0_pc s _clk 8 0 mhz, 50% fmpll_0_clk 8 0 mhz, 50% fmpll_1d0_clk 120 mhz, 50% fmpll_1d1_clk 8 0 mhz, 50% mc_cgm aux clock s elector 0 clock o u t s elector aux clock s elector 1 aux clock s elector 2 s y s tem clock s elector 0 cmu_0 cmu_1 cmu_2 legend: b u ffer clock g a te mc_cgm irco s c_clk 16 mhz s or_p a rt_0_clk s or_p a rt_1_clk s y s _clk peripher a l s et 0 clock 8 mhz 8 0 mhz 50% s y s tem clock divider 0 y 1, y 2, y 3 , .. y 16 y 1, y 2, y 4, y 8 y 1, y 2, y 3 , ... y 16 y 1, y 2, y 3 , ... y 16 y 1, y 2, y 3 , ... y 16 y 1, y 2, y 3 , ... y 16 clocko u t_divider clocko u t 3 0 mhz 50% motor control clock 120 mhz a u xili a ry clock 0 divider 0 s wg clock 20 mhz a u xili a ry clock 0 divider 1 flexr a y clock 8 0 mhz a u xili a ry clock 1 divider 0 flexcan clock 8 0 mhz a u xili a ry clock 2 divider 0 xo s c_clk 8 mhz
AN3324 module software requirements for non applicative peripherals doc id 18311 rev 2 17/37 figure 6. clock configuration flow (c) c. flash and sram wait states depend on mcu work frequency. for this reason it?s a good choice to configure these together with clocks. enable all modes enable all perip. clocks select clock sources for fmpll modules begin enable external oscillators setting run conf. register transition mode set output clock transition mode init pll0 (sys pll) enable plls wait for plls locking transition mode configure auxiliary clock selectors and dividers wait states configuration for flash and ram select system clock derived off the sys pll transition mode end init pll1
AN3324 module software requirements for non applicative peripherals doc id 18311 rev 2 18/37 3.7 clock monitor unit (cmu) the main task of the clock monitor unit (cmu) is to supervise the integrity of various clock sources. user software has to manage the following conditions: loss of external crystal oscillator clock fmpll frequency higher than a (programmable) value set as high reference fmpll frequency lower than a (programmable) value set as low reference spc56el60 includes three cmus: a) cmu_0 to monitor the clock signal of the sphere of replication (sor) and the clock from the crystal oscillator b) cmu_1 to monitor the clock signal used by the motor control related peripherals (etimer, flexpwm, ctu, and adc) c) cmu_2 to monitor the clock signal for the protocol engine of the flexray module use of the cmu is mandatory: if the related modules are used by the application safety function, the user must verify that the cmus are not disabled and their faults managed by the fccu. note: in general, the following two application-dependent configurations must be executed before cmu monitoring can be enabled. 1 crystal oscillator clock monitor (only cmu_0): the software must configure the rcdiv field of the control status register (cmu_0_csr) wi th a value related to the external oscillator frequency. 2 clock signal monitors (cmu_1, cmu_2) : the cmu_x_hfrefr and cmu_x_lfrefr registers must be configured depending on the sor, motor control, and flexray clock frequencies. to later enable the cmus, the flag cme in the respective control status register (cmu_x_csr) must be asserted. 3.8 frequency-modulated phase-locked loop ( fmpll) application software has to check that the system uses the system fmpll clock as system clock before running any safety element function. note: application software can veri fy the current system clock by checking the s_sysclk flag of the me_gs register. s_sysclk equal to 0x4 indicates that the sys tem fmpll clock is used as system clock. each fmpll provides a loss of lock error indication that is routed to the rgm (see section 3.4: reset generation module (mc_rgm) ) and the fccu (see section 3.5: fault collection and cont rol unit (fccu) ). the application software has to enable the respective faul t and configure the fccu to manage it. since in case of fault the system cloc k can be driven by the internal rc oscillator (see section 3.9: internal rc oscillator (ircosc) ), the fault of the fmpll is considered as non-critical fault. note: the pll_fail output is not masked (pll_fail_ma sk flag in the fmpll_x control register (cr) deasserted). to enable the rgm input related to fmpll loss of clock, the registers rgm_ferd and rgm_fear must be configured. to enable the fccu fault path some
AN3324 module software requirements for non applicative peripherals doc id 18311 rev 2 19/37 registers have to be configure (ncf_cfg0, ncfs_cfg0, ncf_toe0, etc.). loss of lock signals from fmpll_0 and fmpll_1 provide the fccu ?non-critical fault? inputs 2 and 3. note: the rgm and fccu configuration includes the reaction in case of fmpll loss of lock. this reaction is application-dependent. 3.9 internal rc oscillator (ircosc) user has to verify the availabi lity and frequency of the intern al rc oscillator and for this reason the frequency meter of the cmu0 (see section 3.7: clock monitor unit (cmu) ) must be exploited. user has to use this feature to measure the rc oscillator frequency using the external oscillator clock as known one and co mpare it to the expected one (16mhz (d) ). note: the reference clock is always the xosc. the measure starts when cmu_csr[sfm] is set. the measurement duration is given by the cmu_mdr register in terms of irc clock cycles with a width of 20 bits. the sfm bit is cleared by the hardware after the frequency measurement is done and the count is loaded in the cmu_fdr. the frequency frc can be derived from the value loaded in the cmu_fdr register (frc = (fosc md) / n) where n is the value in cmu_fdr register and md is the value in cmu_mdr. note: safety related modules which work on the rc clock are: fccu and swt. in case of rc clock failure, these modules stop working. 3.10 flash memory to support the detection of dormant faults in the entire memory array and addressing logic, user must execute array integrity self check (see section 3.10.1: array integrity self check procedure ). this bist is based on functio nality built into the flash control logic. it calculates a misr signature over the array content and thus validates the content of the array as well as the decoder logic. the calculated misr value is dependent on the array content and must be validated by application software. for self check during boot, user has to do the array integrity check over the entire area except over the sectors used for eeprom (ele ctrically erasable programmable read only memory) emulation as only on e of the sectors used for eeprom contains valid data and that the data in this sector varies duri ng ecu (electronic control unit) life time. note: this bist must be started by application software; its result must be validated by reading the corresponding registers in the flash controller after it has been finished. refer to the ?array integrity self check? section in th e ?flash memory? chapter of rm0032 (see b.1: reference documents in appendix b ) for detailed informations about this bist. d. the internal rc oscillator nominal frequency is 16 mhz, but a post trim accuracy of 6 % overvoltage and temperature must be taken into account.
AN3324 module software requirements for non applicative peripherals doc id 18311 rev 2 20/37 3.10.1 array integrity self check procedure array integrity is checked using a pre-defined address sequence (based on ut0[ais]), and this operation is executed on selected blocks. the data to be read is customer specific, thus a customer can provide user code into the fl ash and the correct misr value is calculated. the customer is free to provide any random or non-random code, and a valid misr signature is calculated. once the operation is completed, the results of the reads can be checked by reading the misr value, to determine if an incorrect read or ecc ( error correction code ) detection was noted. array integrity is controlled by the system clock, and it is required that the read wait states and address pipelined control registers in the biu (bus interface unit) be set to match the user defined frequency being used. caution: while array integrity is being executed, flash memory array access through the biu should not be requested. the array integrity check consists of the following sequence of events: 1. enable utest mode. 2. select the block, or blocks to receive array integrity check by writing ones to the appropriate registers in lms or hbs registers. caution: locked blocks can be tested with array integr ity if selected in lms and hbs. it is not possible to do utest operations on the shadow block. 3. if desired, set the ut0[ais] bit to 1 for sequential addressing only. caution: for normal integrity checks of the flash memory, sequential addressing is recommended. if it is required to more fully check the read path (in a diagnostic mode) completely, it is recommended that ais be left at 0, to use the address sequence that checks the read path fully, and examine read transitions. this sequence takes more time. 4. seed the misr um0 through um4 with desired values. 5. set the ut0[aie] bit. a) if desired, the array integrity operation may be aborted prior to ut0[aid] going high. this may be done by clearing the ut0[aie] bit and then continuing with the next step. it should be noted that in the event of an aborted array integrity check the misr registers contains a signature for the portion of the operation that was completed prior to the abort, and it is not deterministic. prior to doing another array integrity operation, the um0, um1, um2 and um3 registers may need to be initialized to the desired seed va lue by doing register writes. 6. wait until the ut0[aid] bit goes high. 7. read values in the misr registers (um0 through um4) to ensure correct signature. 8. write a logic 0 to the ut0[aie] bit. if the flash contents change, the misrs are di fferent: for this reason user should store misr value (used by self check at boot) in a separate flash block that is unselected during misr calculation. note: this test does have some coverage on unselected sectors like sector_eeprom, since the array integrity check always goes through the entire flash array (but only accumulate misrs for selected sectors). therefore, the arra y integrity check signals any ecc error in unselected sectors.
AN3324 module software requirements for non applicative peripherals doc id 18311 rev 2 21/37 3.11 temperature sensors there are two temperature sensors: temperature sensor 0 mapped to adc_0 channel 15 and temperature sensor 1 mapped to adc_1 channel 15. during power up, user software has to read temperature sensors and verify that the values are similar as means of assessing the functionality of the sensors. note: in case of a fault, software must trigger the appropriate reaction. to set a proper threshold the customer must consider that the maximum operating junction temperature is 150 c, for details please refer to spc56el60 datasheet (see b.1: reference documents in appendix b ) and the temperature sensor accuracy is 10 c. it is mandatory to read the 2 sensors synchronously or with a reduced time interval. note: it is important to note that the adc is part of the temperature measuring safety integrity function, and it is therefore required that the bist of the adc must be executed once after the boot even if the adc is not in application use. 3.12 software watchdog timer (swt) the swt has to be enabled and configuration registers have to be hard-locked against manipulation. the time window settings of the swt have to be set to a value less than the pst (e) (process safety time). detection latency is smaller than process safety time. before the safety function is executed, the software must verify that the swt is enabled by reading the swt control register (swt_cr). note: to enable the swt and to hard-lock the configuration register, the wen and hlk flags of the swt control register (swt_cr) must be asserted. the timeout register (swt_to) must contain a 32-bit value that represents a timeout less than the process safety time. caution: swt must be refreshed with a timeline that depends by setted timeout (swt_to value). for this reason it should be configured properly when mcu execute uninterruptible tasks (see section 3.10.1: array integrity self check procedure ) to avoid application reset. e. pst is strictly application dependant.
AN3324 module software requirements for non applicative peripherals doc id 18311 rev 2 22/37 3.13 power management unit (pmu) software has to run core voltage lvd and hvd hardware-assisted self-test after the boot. the pmu provides (to the user ) the software capability to check the run of the bist procedure, generating non-critical faults (ncfs) or critical faults (cf) conditions for the fccu module (see table 2: fault assertion conditions ). at each power-on, the self-test circuitry is able to detect a failure of one of the two voltage detectors and to provide a non critical fault (ncf) to the fccu (see section 3.5: fault collection and cont rol unit (fccu) ). note: the hardware-assiste d self-tests are initiated through the sil fields in the pmu control register (pmuctlr_ctrl). if the self-test pass es, a non-critical fault is triggered (see figure 8: pmu power-on self test flow ). if the self-test fails, a pmuctrl_irqs and critical fault are asserted. the bist execution is controlled by the pmuctrl_ctrl[silht] field (see figure 7: built- in self test flow ). figure 7. built-in self test flow table 2. fault assertion conditions fault number signal ncf[13] lvd bist ok in test mode ncf[14] hvd bist ok in test mode cf[21] lvd/hvd bist failure result in test mode lv d (silht = 00) write silht = 01 idle mode test mode (silht = 01) hvd test mode (silht = 10) write silht = 10 automatically at the end of test
AN3324 module software requirements for non applicative peripherals doc id 18311 rev 2 23/37 figure 8. pmu power-on self test flow read ncf (thru op10) begin manage ncf end init hardware assisted self-test
AN3324 module software requirements for applicative peripherals doc id 18311 rev 2 24/37 4 module software requirements for applicative peripherals the adc, due to its analog part, is the only application peripheral that requires additional hardware bist after the boot. this module is part of the temperature measuring safety integrity function, and it is therefore required that the hwbist functions are executed once after the boot (please refer to an3077 , see b.1: reference documents in appendix b ). 4.1 analog to digital converter (adc) after boot and before starting execution of any safety function, user has to execute adc hwbist functions to check if the adc is functioning correctly and to increase the diagnostic coverage. 4.1.1 self test algorithms three types of self testing algorithms have been implemented inside adc analog. supply self test: algorithm s. it includes the conversion of the adc internal bandgap voltage, adc supply voltage, and adc reference voltage. it includes a sequence of 3 test conversions (steps). the supply test conversions must be an atomic operation (no functional conversions interleaved). resistive-capacitive self test: algorithm rc. it includes a sequence of 19 test conversions (steps) by setting the adc internal resistive digital-to-analog converter (dac). capacitive self test: algorithm c. it includes a sequence of 17 test conversions (steps) by setting the capacitive elements comprising the sampling capacitor/ capacitive dac. the adc implements an additional test channel dedicated for self testing. it also provides signals to schedule self testing algorithms using configuration registers, monitors the converted data using analog watchdog register s, flags the error to fccu in case some failure occurs in any of the algorithms. note: user can execute these tests in cpu mode (one shot or scan mode) and in ctu mode (see figure 9: adc self test in cpu mode using one shot sequence ).
AN3324 module software requirements for applicative peripherals doc id 18311 rev 2 25/37 figure 9. adc self test in cpu mode using one shot sequence 1. in one shot mode, if test channel is enabled, only one step of selected self testing algorithm is executed at the end of the chain. the step number and algorithm to be executed is programmed in stcr3 register. program ncmr0 select channel to be converted for normal conversion program mcr.mode = 0 select one shot mode program sampling duration program stcr3.alg select self test algorithm( 1 ) program stcr2.en = 1 enable self testing channel program mcr.nstart = 1 start the normal conversion program stcr3.mstep step number of self testing alg. is executed similar to a normal functional channel. digital value in stdr1.tcdata ? stdr1.valid setted eoc and ech bits are set in the isr and st_eoc bit is set in stsr1. idle state normal conversions program stcr1[inpsampn]
AN3324 module software requirements for applicative peripherals doc id 18311 rev 2 26/37 4.1.2 analog watchdog the adc provides a monitor (watchdog) for the values returned by its analog portion for self test algorithms. the analog watchdogs are used to determine whether the result of conversion for self test algorithms lie in a particular guard area. for this purpose, separate self test analog watchdog registers have been provided for each algorithm. note: after the conversion of each step of an algorithm, a comparison is performed between the converted value and the threshold values if analog watchdog feature is enabled by setting stawxr.awde bit. if the converted value does not lie between the upper and lower threshold values specified by analog watchdog register of the particular algorithm, corresponding error bit stsr1.err_x is set and step number in which error occurred is updated in stsr1.step_x (in case of c or rc algorithm). also, erroneous data is written in stsr4.datax field. the stsr1.err_x bits generates an interrupt if enabled by corresponding mask bit in stcr2 register. the fault indicati on is also given to fccu via cf and ncf, so that necessary action can be taken. note: before running the hardware self test, the customer must copy the threshold values of the analog watchdogs from test flash into the watchdog registers (stawxr). refer to the "analog-to-digital converter (adc)" section in rm0032 (see b.1: reference documents in appendix b ) for detailed informations about watchdog registers and threshold values.
AN3324 summary doc id 18311 rev 2 27/37 5 summary the described power on self test procedure allow application software to covers all requirements indicated by safety application guide (please refer to an3077 , see b.1: reference documents in appendix b ) as mandatory for power on boot. user should take care that these check are valid only one time and not cover all safety measures that user must implement to have sil3 applications. furthermore, a reference example has been implemented.
AN3324 cpu core initialization doc id 18311 rev 2 28/37 appendix a cpu core initialization user, before mcu initialization must initializ e cpu core and prepare the right environment on what user code is executed. the booting phase include (see section a.2: example of spc56el60 boot file for flash ): define reset vector initialize cpu registers (see section a.1: cpu regi ster initiliazation ) mmu programming initialize stack and sma ll data section pointers a.1 cpu register initiliazation after spc56elx reset, core registers must be initialized to a known value to avoid unexpected fault triggered. spc56elx cores (in lock step configuration) are linked to a checker that verify their alignment: output of core_0 is compared to output of core_1 through rccu (see section 3.3: redundancy control checker unit (rccu) ): if a difference is found the error is forwarded (see figure 10: spc56el60: checking flow ) to fccu (see section 3.5: fault collection and cont rol unit (fccu) ) and to rgm (see section 3.4: reset generation module (mc_rgm) ). figure 10. spc56el60: checking flow core 0 rgm rccu (checker) core 1 fccu
AN3324 cpu core initialization doc id 18311 rev 2 29/37 a.2 example of spc56el60 boot file for flash in boot file user has to provide a reset vector in order to run the application from flash memory. the standard startup process of spc56e lx processor consists in execution of the special boot code which reads specific addresses in a flash memory where reset configuration half word is stored together with boot reset vector pointing to first valid instruction of the code. refer to ?b oot assist module (bam)? section in rm0032 (see b.1: reference documents in appendix b ) . in this boot sequence user must initialize sram and copy data section from flash to sram (this operation is made only when user runs code from flash). as it may see in scratch code below stated, this copy is split into two steps and between them it is inserted software watchdog refresh to avoid device reset. table 3. spc56el60 registers to initialize register ranges r0 - r31 spr1 spr8-spr9 spr22 spr26 - spr27 spr54 spr58 - spr59 spr61-spr63 spr256 spr272 - spr279 spr284 - spr285 spr318 - spr319 spr340 spr400-spr415 spr512 spr528-spr530 spr562 spr570 - spr571 spr573 - spr575 spr604 - spr605 spr628 spr630 acc cr
AN3324 cpu core initialization doc id 18311 rev 2 30/37 finally user must set stack and small data area pointers. ;------- reset configuration half word ------------------------------------- .if __ghs__ .section .rcw .else .section .rcw,,c .endif reset_vector: .long 0x015a0000 # spc56elx - e200 core watchdog off, external boot off, vle on .long _start # code starts at _start ;--------------------------------------------------------------------------- .if __ghs__ ; ghs declarations .section .vletext_init, va .vle .global__ghs_board_memory_init .else ; windriver declarations .section .vletext_init,4,c .endif .global_start .align2 e_add2i.r0,0# debuggers may object to starting at 0. _start: ##--------- set up mmu (begin)-------------------------------------------- #table 0 e_lis r5, 0x10000000@ha e_add16i r5, r5, 0x10000000@l mtspr mas0,r5 # mtspr mas0,r5 e_lis r5, 0xc0000500@ha e_add16i r5, r5, 0xc0000500@l mtspr mas1,r5# mtspr mas1,r5 e_lis r5, 0x00000028@ha e_add16i r5, r5, 0x00000028@l mtspr mas2,r5 # mtspr mas2,r5 e_lis r5, 0x0000003f@ha e_add16i r5, r5, 0x0000003f@l mtspr mas3,r5 # mtspr mas3,r5 tlbwe # write the entry to the tlb #table 1 .... mtspr mas3,r5 # mtspr mas3,r5 tlbwe # write the entry to the tlb #table 2 .... tlbwe # write the entry to the tlb #table 3 .... mtspr mas3,r5 # mtspr mas3,r5
AN3324 cpu core initialization doc id 18311 rev 2 31/37 tlbwe # write the entry to the tlb #table 4 .... mtspr mas3,r5 # mtspr mas3,r5 tlbwe # write the entry to the tlb #table 5 .... tlbwe # write the entry to the tlb se_isync ##--------- set up mmu (end)-------------------------------------------- ##--------- initialise registers --------------------- e_li r1, 5 .... e_li r31, 5 # reset of selected registers mtcrf 0xff,r31 mtspr 285,r31 #tbu .... mtspr 603,r31 ##--------- end initialise registers --------------------- ##------- initialise sram ecc ----------------------------------------------- # doing this in halves for 128k sram to allow for wdog service at # the half-way point. # base address of the internal sram e_lis r5, _sram_base_addr@h e_or2i r5, _sram_base_addr@l # store number of 128byte (32gprs) segments in counter e_lis r6, _sram_size@h # initialize r6 to size of sram (bytes) e_or2i r6, _sram_size@l e_srwi r6, r6, 0x3 # divide sram size by 8 (half sram size in words) mtctr r6 # move to counter for use with "bdnz" # fill sram with known values not registers ############### # never write content of uninitialised registers to sram #### sram_loop1: e_lis r0,0x0 e_stw r0,0x0(r5) # write all 32 registers to sram e_addi r5,r5,4 # increment the ram pointer to next 128byte e_bdnz sram_loop1 # loop for all of sram # service the watchdog now (doing the entire sram init is too long) e_lis r1,0xfff3 e_or2i r1,0x8010 e_li r2,0xa602# sr sequence value 1 se_stw r2,0x0(r1) e_li r2,0xb480# sr sequence value 2 se_stw r2,0x0(r1) # finish initializing sram mtctr r6 # r6 still contains half the sram size in words sram_loop2: e_lis r0,0x0
AN3324 cpu core initialization doc id 18311 rev 2 32/37 e_stw r0,0x0(r5) # write all 32 registers to sram e_addi r5,r5,4 # increment the ram pointer to next 128byte e_bdnz sram_loop2 # loop for all of sram ##--------------------------------------------------------------------------- e_lis r1, __sp_init@h # initialize stack pointer r1 to e_or2i r1, __sp_init@l # value in linker command file. e_lis r13, _sda_base_@h # initialize r13 to sdata base e_or2i r13, _sda_base_@l # (provided by linker). e_lis r2, _sda2_base_@h # initialize r2 to sdata2 base e_or2i r2, _sda2_base_@l # (provided by linker). e_stwu r0,-64(r1) # terminate stack. ##--------- load initialised data values from flash into ram ---------------- #--------- load ".data" section value into ram (un-initialised) ------------- # set gpr9 to the count of the sram load size e_lis r9, __data_size@h # load upper sram load size (# of bytes) into r9 e_or2ir9, __data_size@l # load lower sram load size into r9 e_cmp16ir9,0 # compare to see if equal to 0 e_beq romsdatacopy # exit cfg_romcpy if size is zero mtctr r9 # store # of bytes to be moved in spr ctr e_lis r10, __data_rom_addr@h # load address of first sram load into r10 e_or2i r10, __data_rom_addr@l # load lower address of sram load into r10 e_subi r10,r10, 1 # decrement address to prepare for romcpyloop # load sram base address (__data_sram_addr) for loading instructions into r5 # (__sram_cpy_start = addr(.data)) e_lis r5, __data_sram_addr@h # load upper sram address into r5 e_or2i r5, __data_sram_addr@l # load lower sram address into r5 e_subi r5, r5, 1 # decrement address to prepare for romcpyloop romdatacpyloop: e_lbzu r4, 1(r10) # load data byte at r10 into r4,incrementing (update) rom address e_stbu r4, 1(r5) # store r4 data byte into sram at r5 and update sram address e_bdnz romdatacpyloop # branch if more bytes to load from rom ##--------- load ".sdata" section value into ram (un-initialised) ------------------ romsdatacopy: e_lis r9, __sdata_size@h # load upper sram load size (# of bytes) into r9 e_or2ir9, __sdata_size@l # load lower sram load size into r9 e_cmp16ir9,0 # compare to see if equal to 0 e_beq romcpyend # exit cfg_romcpy if size is zero mtctr r9 # store # of bytes to be moved in spr ctr e_lis r10, __sdata_rom_addr@h # load address of first sram load into r10 e_or2i r10, __sdata_rom_addr@l # load lower address of sram load into r10 e_subi r10,r10, 1# decrement address to prepare for romcpyloop # load sram base address (__sdata_sram_addr) for loading instructions into r5 # (__sdata_sram_addr = addr(.data)) e_lis r5, __sdata_sram_addr@h # load upper sram address into r5
AN3324 cpu core initialization doc id 18311 rev 2 33/37 e_or2i r5, __sdata_sram_addr@l # load lower sram address into r5 e_subi r5, r5, 1 # decrement address to prepare for romcpyloop romsdatacpyloop: e_lbzu r4, 1(r10) # load data byte at r10 into r4,incrementing (update) rom address e_stbu r4, 1(r5) # store r4 data byte into sram at r5 and update sram address e_bdnz romsdatacpyloop # branch if more bytes to load from rom romcpyend: ##--------- end load un-initialised values into ram --------------------- .if __ghs__ e_bl main .else bl __init_main .endif
AN3324 additional information doc id 18311 rev 2 34/37 appendix b additional information b.1 reference documents safety application guide for spc56el60 (an3077, doc id 163 84). spc56el60 32-bit mcu family built on the embedded power architecture ? (rm0032, doc id 15265). getting started tutorial for spc56el60 (an3121, doc id 16853). 32-bit power architecture ? microcontroller for automotive sil3/asild chassis and safety applications ( spc56el60l3, spc56el60l5 datasheet, doc id 15457). b.2 acronyms table 4. acronyms acronym name adc analog to digital converter bam boot assist module bist built in self test biu bus interface unit cf critical fault cmu clock monitor unit crc cyclic redundancy check dma direct memory access ecc error correction code ecu electronic control unit eeprom electrically erasable pr ogrammable read only memory fccu fault collection and control unit fmpll frequency modulated phase-locked loop hvd high voltage detector intc interrup t controller irc internal rc oscillator lvd low voltage detector mcu microcontroller unit ncf non critical fault pmu power management unit rccu redundancy control checking unit rgm reset generation module sag safety application guide
AN3324 additional information doc id 18311 rev 2 35/37 sif safety integrity function sscm system status and configuration module stcu self test control unit swt software watchdog timer xosc external oscillator table 4. acronyms acronym name
AN3324 revision history doc id 18311 rev 2 36/37 revision history table 5. document revision history date revision changes 03-jan-2011 1 initial release. 25-sep-2013 2 updated disclaimer.
AN3324 doc id 18311 rev 2 37/37 please read carefully: information in this document is provided solely in connection with st products. stmicroelectronics nv and its subsidiaries (?st ?) reserve the right to make changes, corrections, modifications or improvements, to this document, and the products and services described he rein at any time, without notice. all st products are sold pursuant to st?s terms and conditions of sale. purchasers are solely responsible for the choice, selection and use of the st products and services described herein, and st as sumes no liability whatsoever relating to the choice, selection or use of the st products and services described herein. no license, express or implied, by estoppel or otherwise, to any intellectual property rights is granted under this document. i f any part of this document refers to any third party products or services it shall not be deemed a license grant by st for the use of such third party products or services, or any intellectual property contained therein or considered as a warranty covering the use in any manner whatsoev er of such third party products or services or any intellectual property contained therein. unless otherwise set forth in st?s terms and conditions of sale st disclaims any express or implied warranty with respect to the use and/or sale of st products including without limitation implied warranties of merchantability, fitness for a parti cular purpose (and their equivalents under the laws of any jurisdiction), or infringement of any patent, copyright or other intellectual property right. st products are not designed or authorized for use in: (a) safety critical applications such as life supporting, active implanted devices or systems wi th product functional safety requirements; (b) aeronautic applications; (c) automotive applications or environments, and/or (d) aerospace applications or environments. where st products are not designed for such use, the purchaser shall use products at purchaser?s sole risk, even if st has been informed in writing of such usage, unless a product is expressly designated by st as being intended for ?automotive, automotive safety or medical? industry domains according to st product design specifications. products formally escc, qml or jan qualified are deemed suitable for use in aerospace by the corresponding governmental agency. resale of st products with provisions different from the statements and/or technical features set forth in this document shall immediately void any warranty granted by st for the st product or service described herein and shall not create or extend in any manner whatsoev er, any liability of st. st and the st logo are trademarks or registered trademarks of st in various countries. information in this document supersedes and replaces all information previously supplied. the st logo is a registered trademark of stmicroelectronics. all other names are the property of their respective owners. ? 2013 stmicroelectronics - all rights reserved stmicroelectronics group of companies australia - belgium - brazil - canada - china - czech republic - finland - france - germany - hong kong - india - israel - ital y - japan - malaysia - malta - morocco - philippines - singapore - spain - sweden - switzerland - united kingdom - united states of america www.st.com

▲Up To Search▲

Price & Availability of AN3324

	To Download AN3324 Datasheet File
If you can't view the Datasheet, Please click here to try to view without PDF Reader .